The field of the invention generally relates to testing of integrated circuit designs, and more specifically built-in test systems which utilize integrated debug circuitry incorporated within the integrated circuit under test.
During the development of integrated circuits, particularly in Large Scale Integrated Circuits (LSICs), various software tools are utilized to check and test the operation and functionality of the circuits under test. Two software tools that are commonly utilized are state and timing simulators.
The state simulator is software that emulates a circuit under test, such as a LSIC. The purpose of the state simulator is to mimic the circuit under test so that inputs to and outputs from the circuit under test can be identified. One or more test vectors are entered into the state simulator in order to produce inputs, and determine the resulting outputs for the circuit under test. A test vector is essentially a set of logic states that are imposed upon corresponding nodes in the circuit under test. A set of test vectors typically make up each test case. The test vectors are entered into the state simulator sequentially, usually one vector per clock phase. The state simulator produces state data, which is essentially a large matrix of logic values for nodes in a circuit, for each phase transition, or time step, as determined by the state simulator. For a given set of test vectors, the state simulator identifies the input for the circuit under test (microprocessor test input) and the output for the circuit under test (expected microprocessor output).
A timing simulator is software that determines timing information for each logical path contained in the circuit under test. In general, a timing simulator measures elapsed time for signals to propagate to the circuit elements by providing the times at which each input signal arrives at each node in a path relevant to a clock. Paths are usually scored in order of speed so that a designer can find ways to speed up a slow path and thus enable a higher frequency of operation. The timing data that is produced by the timing simulator includes a list of paths, typically ordered slow to fast, with the time that each transition occurred at each node for each path.
Other software tools are available in the industry for collecting node toggle (transition) information, xe2x80x9cstuck atxe2x80x9d information and delay fault information. These tools focus on process defects, typically, one fault at a time.
U.S. Pat. No. 5,818,850, (the xe2x80x9c""850 patentxe2x80x9d) assigned to the assignee of the present invention, entitled Speed Coverage Tool And Method, issued Oct. 6, 1998, and hereby incorporated herein by reference in its entirety, describes a test coverage tool and method to determine the adequacy of test vectors for a state simulator for exercising logical paths in a logical circuit design. The speed coverage tool of the ""850 patent generally compares state data from a state simulator and timing data from a timing simulator in order to validate whether a set of test vectors cover a simulated timing test.
Once the microprocessor test inputs and the expected microprocessor outputs are identified using the state simulator and other software tools, the microprocessor test inputs are applied to the circuit under test. Ideally, the results from the circuit under test would match the expected microprocessor outputs previously obtained from the state simulator. Once these vectors agree, the testing of the circuit under test is completed and the functionality of the circuit under test has been determined to be correct.
More often than not, the actual microprocessor output from the circuit under test does not match the expected microprocessor output obtained from the state simulator. Troubleshooting on the circuit under test must then be undertaken to determine the problems internal to the circuit. It has become very difficult to diagnose failures in, and to measure the performance of, state of the art microprocessors such as LSICs. This is because modern microprocessors not only run at very high clock speeds, but many of them also execute instructions in parallel, out of program order, and speculatively. Moreover, visibility of the microprocessors"" inner state has become increasingly limited due to complexity of the microprocessors and of practical constraints on the number of external pads, or test points, that can be provided on the circuit under test for testing purposes.
In the past, the traditional failure, diagnosis and performance measurement tools have been external logic analyzers and in-circuit emulators. Logic analyzers are capable of monitoring signals on the chip pads, test points, or other externally accessible system signals, and capturing the state of these signals. Unfortunately, logic analyzers rely solely on externally accessible signals to accomplish this, and do not directly monitor test signals that are internal to the chip itself. In-circuit emulators, on the other hand, are used to mimic the functional characteristics of a new microprocessor in a system environment and to add visibility to certain data values within a microprocessor. Such devices emulate the functionality of the microprocessor. By their very nature, they cannot give a complete and accurate representation of the performance characteristics of an actual silicon device. Therefore, they are primarily useful only for developing and debugging system software.
U.S. Pat. No. 5,867,644, (the xe2x80x9c""644 patentxe2x80x9d) entitled System And Method For On-Chip Debug Support And Performance Monitoring In A Microprocessor, issued Feb. 2, 1999 to Gregory Ranson, is assigned to the assignee of the present invention, and is incorporated herein in its entirety. The ""644 patent describes user configurable diagnostic hardware which is contained on the chip with a microprocessor for the purpose of debugging and monitoring the performance of the microprocessor. A programmable state machine is used in the ""644 patent and is coupled to on-chip and off-chip input sources. The programmable state machine may be programmed to look for signal patterns presented by the input sources, and to respond to the occurrences of a defined pattern (or sequence of defined patterns) by driving certain control information onto a state machine output bus. On-chip devices coupled to the output bus take user definable action as dictated by the bus. The input sources include on-chip user configurable comparators located within the functional blocks of a microprocessor. The comparators are also coupled to storage elements within the microprocessor, and are configured to monitor nodes to determine whether the states of the nodes match the data contained in the storage elements. The programmer may change the information against which the states of the nodes are compared as well as the method by which the comparisons are made by changing data in the storage elements. Counters may also be included in the output device and may be used as state machine inputs, so one event may be defined as a function of a different event having occurred a certain number of times. The output device typically also includes circuitry for generating internal and external triggers. User configurable multiplexer circuitry may be used to route user selectable signals from within the microprocessor to the chip""s output pads, and to select various internal signals to be used as state machine inputs.
Once a problem is identified within a circuit under test, on-board diagnostic hardware can be used to troubleshoot the circuit. However, before the on-board diagnostics can be used, they must be configured correctly for the testing desired. This is typically done by a test hardware vector. Additionally, the circuit under test must be placed in a known state, which is typically performed with vector initialization code.
Therefore, once a problem has been identified in a circuit under test, there are three vectors associated with this additional debug testing when onboard diagnostic hardware is used: a vector initialization code places the circuit under test into a known state; a microprocessor test input is used to test the functionality of the circuit under test, and a test hardware vector is used to ensure the diagnostic hardware onboard the circuit under test is configured correctly to receive and store test data. These last two vectors, the microprocessor test vector input and the test hardware vector are combined into an integrated debug trigger image. Ideally, the output of the circuit under test when it receives the integrated debug trigger would be the expected microprocessor output. However, the presence of the test hardware vector can affect the output of the circuit under test so that, even when the circuit under test is operating correctly, an output other than the expected microprocessor output is obtained. When the result differs from the expected microprocessor output, the tester is unsure if the output is a result of a faulty circuit or the effect of the test hardware vector. Therefore, before the integrated debug trigger image is loaded into the circuit under test, the expected effects of the test hardware vector on the expected microprocessor output must be xe2x80x9cbacked outxe2x80x9d (i.e., eliminated or minimized) to ensure the expected microprocessor output is received when the circuit under test is operating correctly. This iterative process currently requires numerous runs through the state simulator software to ensure the correct expected microprocessor output is known. Each of these runs may require several hours of computer time to complete.
A need exists for a testing system and method which will allow the tester to combine the microprocessor test input with the test hardware input in a manner that ensures the expected microprocessor output is not affected. A further need exists for a user interface which will allow the combination of the microprocessor test input and the test hardware input without requiring the resulting integrated debug trigger image be rerun through the state simulator. A further need exists to combine the microprocessor test input and the test hardware input in real or near-real time.
The invention is directed to a method and apparatus for real time manipulation of a test vector or test case to access microprocessor state machine information using an integrated debug trigger. The invention preferably includes the ability to manipulate a xe2x80x9cfailingxe2x80x9d vector and insert a code fragment to program the integrated debug trigger without disrupting the failing test vector or test case. The invention preferably simplifies and allows the real time programming of the integrated debug trigger, also known as the logic analyzer, which previously required resimulation of the integrated debug trigger code. That is, the invention preferably provides for immediate or real time editing of the integrated debug trigger vector using appropriate vector tester hardware and/or software and includes the ability to add the integrated debug trigger vector on the test vector initialization without disrupting the test case vector.
When implemented in software, the elements of the present invention are essentially the code segments to perform the necessary tasks. The program or code segments can be stored in a processor readable medium or transmitted by a computer data signal embodied in a carrier wave, or a signal modulated by a carrier, over a transmission medium. The xe2x80x9cprocessor readable mediumxe2x80x9d may include any medium that can store or transfer information. Examples of the processor readable medium include an electronic circuit, a semiconductor memory device, a ROM, a flash memory, and erasable ROM (EROM), a floppy diskette, a compact disk CD-ROM, an optical disk, a hard disk, etc., while transmission media may include, for example, a fiber optic medium, a radio frequency (RF) link, etc. The computer data signal may include any signal that can propagate over a transmission medium such as electronic network channels, optical fibers, air, electromagnetic, RF links, etc. The code segments may be downloaded via computer networks such as the Internet, an intranet, etc.